I'm all for webp and webm being added

the discussion on svg support being added by default has been discussed many times before

Well, the only vector format supported by browsers is SVG. We can of course tell our site integrators to shove it and have to enter the paths to their SVGs manually but this is hardly a workable, modern CMS. No wonder people are flocking to WordPress.

We can of course tell our site integrators to shove it and have to enter the paths to their SVGs manually but this is hardly a workable, modern CMS. No wonder people are flocking to WordPress.

They wont get svg in wordpress either (unless something just changed) https://www.wpbeginner.com/wp-tutorials/how-to-add-svg-in-wordpress/

Regarding WordPress, I am not making comments about WP vs J lightly. On my WordPress 5.4 local site I use for development I can upload SVG files to the Media Library and I can insert them just fine in posts using the Block Editor (Gutenberg) by selecting them in the Media Manager, uploading them directly or linking to them by URL. I actually tested it AGAIN just now. Go ahead, download and install WordPress using their "famous 5' installation" and give it a whirl.

Now let's see in my Joomla 3.9.16 site of the same vintage. I can't even upload SVGs to the Media Manager. I need to know which THREE (3) options to change. Even if I do that, I cannot insert them in articles or select them anywhere else where images are allowed. I can only link to them by URL.

Here are some further thoughts about image file support in Joomla.

The media manager currently supports XCF and will even try to display an inline preview. As far as I can tell from searching the MDN it's not supported by browsers. Maybe it was supported circa 2004 when Mambo was around. If memory serves, it was supported only on Firefox on Linux. Admittedly, 16 years later it's hard to be sure.

WebP is not supported on mobile Safari. Its utility is very limited for that reason, especially since Joomla doesn't have any native support for the <picture> tag when selecting images using the Media form field. Therefore you can't realistically use WebP using the image picker because it would be useless. In the WYSIWYG editors you can always key it in manually in a picture element, meaning this is probably a useless change except for simply being able to preview your WebP.

WebM, like MP4, cannot be previewed and Joomla does not have a video select field. As far as I can tell you can't insert a video object using TinyMCE unless you drop to source view. So that's just a meaningless change put there just in case something changes.

SVG, however, is supported by all modern browsers, it can be previewed inline and it is tremendously useful for people building real world sites, it being the only vector format supported in modern browsers and really small nonetheless. Moreover, everything can be addressed by icon fonts and not everyone is like our company, creating custom icon fonts for their sites.

I do get the security issues regarding SVG support. However, this is a rather bogus argument when I have already contributed MediaHelper::canUpload since Joomla 3.4. This code, which was part of my Admin Tools Professional security solution, will completely block the upload if the file contains a <script> tag. Therefore it addresses the security concerns of SVGs.

Can you manually upload malicious SVGs if you override Joomla's upload protections or if you use FTP/SFTP/your host's file manager? Sure you can... in the same way you can upload malicious JavaScript and PHP files on a site you have total control over i.e. it falls under the category "I can hack myself".

I have tested this item ✅ successfully on 2c00477

Tested successfully according to the description with svg, webp and webm videoformat

I do get the security issues regarding SVG support. However, this is a rather bogus argument when I have already contributed MediaHelper::canUpload since Joomla 3.4. This code, which was part of my Admin Tools Professional security solution, will completely block the upload if the file contains a <script> tag. Therefore it addresses the security concerns of SVGs.

I wonder why svg has always been rejected then

@brianteeman I can tell you exactly why it was always being rejected. But I need to take the scenic route to get there.

SVG files can have JavaScript. This used to be a problem. The keyword here is "used to". The article I linked you to is from ten years ago 😄

In the meantime, certain things have changed.

Since Joomla 3.4 we have the code I mentioned which detects scripts in any uploaded file and rejects it from ever being uploaded. Of course this is not a panacea because an enterprising miscreant could plausibly use event attributes. This will become irrelevant in Joomla 4 with content security policy support; the default settings prevent inline event attributes unless the resource uses the CSR token which is not the case with <img> tags.

But what about Joomla 3 and right now? I have good news that people may have not yet heard.

Modern browsers do not allow script execution in SVG files when they are included in <img> tags. You'd have to include your SVGs as an <object> which can only be done by manually writing HTML code in the WYSIWYG editor's source code tab so it's another case of "I can hack myself".

If I recall correctly that last change about SVGs in IMG tags not executing code only took place circa late 2017 for the security reasons I linked to at the top of this reply. All the discussion in Joomla was based on the outdated assumption that an SVG loaded through an IMG tag would be a security nightmare. This is simply no longer the case.

So, to put it clearly: the only reason Joomla has consistently rejected SVG support the last 2 ½ years is that the people making these decisions have stale security knowledge. Hopefully we can now shift the discussion to how browsers work in the real world, today versus an outdated mental model that's not been relevant in ages.

Are you sure you don't have something extra installed on your wp install. I just checked with a copy of 5.4 that only has backup installed and I cannot add svg images

(Or maybe it was because the only svg I had to hand was the joomla logo :) )

Maybe it is something yoast is doing then because I still cant upload svg

Nicholas is right, an SVG being referenced in an -tag can hardly do any harm, so what's the threat scenario here?

SVGs, if embedded directly, in an object-tag or if opened directly, can execute JS either in an <script>-Tag or using one of the gazillion on*-event attributes. So, if you i.e. get a user to click on a link to a manipulated SVG file, you will end up with a script execution.
Now, let's think about a low-privilege user (i.e. editor) who is uploading such a manipulated SVG with an onmouseenter attribute and is sending that link to the site's super administrator with the instruction to "quickly look at that image because it has a glitch in Firefox". The super admin clicks on that link, JS is executed in the super admin's browser session, allowing the JS to execute whatever task with super administrator privileges – in that case, we can use the script to upgrade the editor's account to a full privilege account, resulting in a full compromise of the site.

The current HTML filter logic in Joomla does it's very best to prevent exactly that scenario by filtering malicious tags and attributes in non-superadmin input. With SVG upload being added and being enabled by default, that layer of defense is significantly weakened.

I'm personally open for an opt-in support (just like users can chose to allow <script>-Tags for non-superadmins, but a default-on setting is a no-go.

I'm personally open for an opt-in support (just like users can chose to allow <script>-Tags for non-superadmins, but a default-on setting is a no-go.

That's what we have right now isn't it? You optin by adding the mime types etc

I believe that it is wrong to forbid everyone to upload. I think that it is necessary to bind to rights. That is, to limit the upload of file types by user rights and, accordingly, make not one input input, but several broken into rights. By default, for administrators and a super user, allow svg, prohibit others and the administrator himself can limit what to download and to whom.

I'm personally open for an opt-in support (just like users can chose to allow <script>-Tags for non-superadmins, but a default-on setting is a no-go.

That's what we have right now isn't it? You optin by adding the mime types etc

You’ll still lack the changes to the model that are added in this PR

I recently did file uploads on the front. And I realized that I can’t specify which user groups can upload which files. I think you need to expand all the same settings.

I will soon do this in my file manager and will be able to demonstrate this in work.

As far as I can tell you can't insert a video object using TinyMCE unless you drop to source view.

You can use the tinymce media button - admittedly its not that friendly but it does work

@brianteeman why not just expand the settings? what are the problems?

I just echo what the JSST lead said and that no cms supports svg out of the box

JSST who is it? how to decipher.
I just can’t understand why it’s impossible to expand the settings and make adequate presets for this. Where are the facts that it is unsafe in this format.

#28599 (comment)

@brianteeman I missed some of your earlier messages. Thanks about the video embed, it’s REALLY well hidden 😮 I was just using JCE by default.

Regarding the Media Manager options, they are a weird little case and I’ll have to get technical (sorry). All three options in the test instructions? They control uploads. Only. They don’t control image selection. The image selection is hard-coded in the model I modified in this PR.

What user expect – even experienced ones like my wife – is that the option about image file extensions has some effect on which files can be selected in the Media field. This is currently not the case :/ Making SVG (and JPEG2000 and you-name-it) support opt-in would require modifying the model to use the extensions defined in the media manager as the accepted extensions for image files. In case it’s not set we can use the current default list. This is necessary because the Media field’s layout simply loads the images view of com_media.

This would still be a problem in the case that @SniperSister explained BUT it’s opt-in and you only get to do that if you understand what you’re doing. Also, I would posit that the number of practical use cases where your Manager user can be an untrusted scoundrel is rather low. Also, it’s not a practical attack. The Manager would need to create an object or embed tag – which CAN be filtered in Joomla’s Global Configuration – to have code executed. If the Super User opens the file directly in a browser he runs untrusted JS in the context of a blank browser window which is the baseline threat level when visiting any random Internet site with JS enabled, i.e. the default threat level for basically everyone. And if we want to really be pedantic about it we CAN implement code that goes through the SVG structure and removes script tags and inline event handlers.

I can implement either or both of these suggestions BUT I need to know if they are going to be accepted before I start working on them. The reason is that we’re talking about a fair chunk of my time that I am only willing to allocate to core contribution if there’s a fighting chance of my contribution seeing the light of day. Otherwise it’s far easier for me to do a one-line core hack on the sites I need to support SVGs (in the same way that it’s easier for a tight-rope artist to go between two buildings balancing on a tight rope than getting the elevator down, crossing the street and taking the other elevator all the way up, i.e. whoever is reading this, DON’T TRY THIS AT HOME).

If the Super User opens the file directly in a browser he runs untrusted JS in the context of a blank browser window which is the baseline threat level when visiting any random Internet site with JS enabled

Nope, that was my point: if the JS in the SVG is executed in the origin context of the hosting domain, so a JS hosted in a Joomla site can i.e perform an AJAX call that has access to the current session cookie. It’s not a isolated context.

@nikosdion I did a quick test with an SVG in /images and accessing the administrator interface seemed to work at the first glance, but I’ll do a proper test case tomorrow and post an update here

You are missing the point

Actually I'm not.. modern image formats & handling methods, which can have a significant impact on sites, are NOT being used in J!

Yes they can have a significant impact on sites. They can lead to them being hacked. That's the point.

just discovered that i've not the power to reopen this 1
@joomla/cms-maintainers can you do it this please?

@alikon I can't either. Seems only the author can do that with a PR, or it is because the branch has been deleted meanwhile, so it shows "unknown repository" as branch.

can someone tell what exactly security issue with use of SVG, and in which cases?
for SVG in <img> tag (not for inline SVG, because it is obvious),

because it sounds like:

- you see an alien? 
- no,
- but it there

@Fedik Follow the links in my reply from early April. I linked to this information so that people who are interested in understanding what is the security context of using SVG files, like you, could follow them.

@richard67 Can't reopen it. Trying to update my Joomla fork I cocked it up so I decided the best way is to delete my forked repo and start afresh. At this point I had no open PRs in Joomla so it didn't sound like a bad idea at all. Well... that branch for this PR? Gone. You can still take a look at my plugin and see how I did it. It simply patches the Joomla core classes in memory.

If you are sure you want me to make a PR I can reverse engineer the patches I am doing in my plugin and convert them into a PR. However, I will only spend this time IF AND ONLY IF I have the JSST come here and explicitly state that they will accept a PR based on the SVG sanitization I am doing in the plugin I linked to in my PR's comment. If they don't explicitly say that then I won't waste my time and you can still use my plugin.

@nikosdion thanks for link, I just wanted to write that there no issue with <img>, but you explained it much better.
Only issue if someone open the file directly.

@SniperSister we do not need to filter whole SVG, or do any content manipulation, we already have a fancy method that after some improvement can be much useful, InputFilter::isSafeFile()

All we need is to check whether SVG contain <script> tag and stop upload if any.

@Fedik We already discussed this. It is possible to have attributes with inline JavaScript such as onclick. Using sanitization addresses this since only explicitly allowed elements and attributes will make it into the resulting SVG.

The problem is that the project thinks this is a “major change” and won't include it in Joomla 3. At the same time, Joomla 3.10 backports features from Joomla 4 which have a far more serious and far reaching impact.

The real problem that nobody admits is who takes responsibility for the code. I am ready to do so, as I've always done for the code I contributed to the project. The thing is, the leadership doesn't want to take that tiny sliver of responsibility for letting me contribute my code. So we are at a stalemate and I created my own plugin to manage SVGs in my own sites.

@marcodings can this be made possible? In my personal opinion it's a very important bugfix / function.

However, I will only spend this time IF AND ONLY IF I have the JSST come here and explicitly state that they will accept a PR based on the SVG sanitization I am doing in the plugin I linked to in my PR's comment. If they don't explicitly say that then I won't waste my time and you can still use my plugin.

Having that topic on the agenda for today's JSST meeting

Beside the technical aspects I want to say thank you to @nikosdion that despite of this long and frustrating discussion he has not given up and is still contributing to the project and still is willing to work on this issue. This shows your love to the project, @nikosdion , thank you very much for that.

We already discussed this. It is possible to have attributes with inline JavaScript such as onclick. Using sanitization addresses this since only explicitly allowed elements and attributes will make it into the resulting SVG.

if ('onclick' in $svgContent or 'script' in $svgContent): 
  then stop upload

(and some other events attributes)

easy 😃

The real problem that nobody admits is who takes responsibility for the code.

I understood

@Fedik Unfortunately it's not that easy :( You really need to go through the DOM to sanitize the file based on an allow list of tags and attributes. The problem is that browsers use their very lax and forgiving SGML parser even on what is ostensibly a strict XML file type like SVG. There are various crap a malicious actor can do to obscure the fact they are using an attribute and the browser still parse it. Your only real defense is full parsing, sanitization and writing out the sanitized file.

Maybe a stupid question but I could also upload a malicious php file into template when I am a superadmin or not? Where is this security risk different from uploading an insecure svg?

@coolcat-creations yes you could which is why the default access to do that is super admin. The equivalent would be making the default access for media manager is also super admin

@coolcat-creations Besides what @brianteeman already said, do keep in mind that the media manager settings apply to all uploads across all components in Joomla. Even if Media Manager was Super User only you could still upload a malicious SVG through a WYSIWYG editor, a forum component, a support tickets component etc. So what we do in that little configuration page has an impact throughout the Joomla ecosystem. That's why I first closed this PR in favor of going to a full implementation of SVG sanitization.

Thank you both for explaining. I am looking forward to use svgs in Joomla without any hassle. Til date I upload them by ftp and copy paste the paths which is just not nice for the customers to handle. They often delete the "ghostpath" by accident and can't select it back...

Thank you both for explaining. I am looking forward to use svgs in Joomla without any hassle. Til date I upload them by ftp and copy paste the paths which is just not nice for the customers to handle. They often delete the "ghostpath" by accident and can't select it back...

Just install alternative media manager, like Quantum, for example :)

However, I will only spend this time IF AND ONLY IF I have the JSST come here and explicitly state that they will accept a PR based on the SVG sanitization I am doing in the plugin I linked to in my PR's comment. If they don't explicitly say that then I won't waste my time and you can still use my plugin.

@nikosdion issue was discussed during the meeting and proposal for "min requirements for SVG support" are up for comment for the other team members. Will share the outcome on thursday!

@SniperSister That's perfect! Thank you. Just a heads up, I will be mostly unavailable between Thursday afternoon and Friday afternoon. I will try to respond as soon as I can when I receive your feedback. Have a great evening!

@nikosdion as promised, here's the feedback from the meeting:

The JSST will accept the addition of SVG support to the CMS, if two requirements are met:

• a SVG sanitization library is used (like in your plugin)
• SVG upload for non super-admins is disabled by default

Since upload restrictions are global and not per user level what you ask is simply not possible. It is also utter nonsense since a Super User can already install a file manager and circumvent Joomla’s sanitization for SVG files.

I would like to once again underscore the baldfaced hypocrisy of your decision. Joomla 4 allows for unsanitized SVG uploads from everybody.

People, if you want SVGs in Joomla 3 either use my plugin or JCE Pro. I give up.

Since upload restrictions are global and not per user level what you ask is simply not possible. It is also utter nonsense since a Super User can already install a file manager and circumvent Joomla’s sanitization for SVG files.

Well the aim is just to have it disabled by default?

I would like to once again underscore the baldfaced hypocrisy of your decision. Joomla 4 allows for unsanitized SVG uploads from everybody.

I have not checked that myself but george told us 4.x only shows uploaded SVG's but do not allow to upload them.

People, if you want SVGs in Joomla 3 either use my plugin or JCE Pro. I give up.

That would be the case for 3.x anyway. I personally would add that SVG cleanup and upload feature to 4.x only.

Since upload restrictions are global and not per user level what you ask is simply not possible. It is also utter nonsense since a Super User can already install a file manager and circumvent Joomla’s sanitization for SVG files.

Sorry, that's unclear in my first statement:
SVG upload should be disabled by default, turning it on should be a super-admin setting (like it is today). So, no need for per-user-level restrictions and no blocker from our side.

That's more clear. @nikosdion Is this ok for you?

@SniperSister This is completely different to what you wrote. Let me explain what I can do (and why).

I am NOT touching the extensions and MIME types allowed. As a result, SVG upload is disabled by default. A Super User needs to go in there and change them. So, by default, there is no SVG support unless you are BOTH a Super User AND know what the heck you're doing. I think that is more than the minimum bar you set.

Change MediaHelper and BannerHelper to respect the Media Manager's settings about which extensions are considered images. This creates feature parity with Joomla 4 and is reasonable – as far as users are concerned, the image types option currently "does nothing" which is bad UX. Moreover, it allows for the display of SVGs as images and picking them in an image picker IF AND ONLY IF a Super User explicitly adds the SVG extension as a valid image extension.

When uploading files, if the file has an svg extension (case insensitive) it will go through the SVG sanitizer library. If the sanitizer fails to sanitize the file we throw a RuntimeException which forces the upload the fail with a message that this is not a valid SVG file.

Would that be OK?

Can you clarify if we are talking about J3, J4 or both

This is completely different to what you wrote. Let me explain what I can do (and why).

Sorry, it has been a loooong day ;)

Would that be OK?

Yes, perfectly fine for me.

Can you clarify if we are talking about J3, J4 or both

The JSST statement is for both, J3 and J4. We have no security-related objections against an implementation in any of those two versions.

If a J3 PR is accepted by the maintainers (not counting me in here as I honestly neither deserve nor fulfill that role) under semver-aspects is a question that I can't answer.

My very personal opinion as a Joomla user is that SVG supports adds so much additional value to 3.x, that it should be added to it, especially having the two more years of support in mind.

I got here because my J4 beta template styles editor does not even show the logo.svg from templates/cassiopeia/images. I'm trying to assess all the issues of svg presented here and various related settings. But I am surprised that the default template has svg files that cannot by default be edited/changed in the template styles editor.

What happened to this? We currently have svg upload optional but this bit of code on line 300 of MediaHelper.php (in J4):

$xss_check = file_get_contents($file['tmp_name'], false, null, -1, 256);

ensures that tests against all of the html_tags tags will never find any. So no sanitization and no check for bad svg content.